With the growing popularity of Internet video and Internet TV, there is an increasing need for adaptive streaming solutions that allow continuous playback and best user experience under varying network conditions. The concept of adaptive streaming is based on the idea to adapt the bandwidth required by the video stream to the bandwidth available on the network path between the streaming source and the client, wherein the bandwidth is adapted by changing the bit-rate (i.e. the quality) of the video stream.
Currently a number of HTTP-based adaptive streaming (HAS) protocols have been developed and best practises of these solutions are currently condensed in an emerging ISO standard ISO/IEC 23001-6 which is referred to as the MPEG Dynamic Adaptive Streaming over HTTP (MPEG DASH). In HAS solutions a content stream is usually partitioned into segments (also referred to as “chunks”) wherein each of these segments may be encoded in different quality levels (representations). A content delivery network (CDN) is typically used to efficiently deliver segments to a large number of content processing devices.
The segments and their different representations are described in a so-called manifest file, which may comprise information about the segments in the stream (segment identifiers, location, play-out time, etc.) and the temporal relation between different segments in the stream. A client in a content processing device may use a manifest file to request segments from the network and process the segments for play-out. The client may be configured to switch between different representations depending on network conditions.
MPEG DASH and the other adaptive streaming solutions have been developed for delivery over unmanaged (best effort) networks and the Internet. In order to cope with unexpected jitter and congestion, and in order to reduce the risk of a buffer underrun, the buffering performed at the client is substantial compared to the total end-to-end delay between the source and the play-out of the content processing device.
HAS clients typically use a (preconfigured) play-out buffer of at least three complete segments before play-out is started. The buffer increases linearly with the segment size and therefore easily reaches 30 seconds or more. Moreover, in order to reduce the risk that not sufficient segments are available to fill the play-out buffer, the client is configured such that the first segment that is going to be requested by the client (upon joining the streaming event) will be a segment that is made available earlier by the streaming source (typically three segments earlier) than the segment that has been made available by the streaming source upon joining the streaming event.
Hence, a substantial latency (delay) exists between the play-out of a live streaming event by a HAS client and the play-out of the live stream by other content processing devices that are based on other transport mechanisms such as conventional broadcast or multicast streaming.
For the delivery of content, in particular live content, over managed networks (e.g. a TV channel), it however is desired to have approximately the same play-out time of the content on different content processing devices (e.g. TVs, STBs, tablets, smart phones, etc.), which may receive said content via different transport mechanisms (e.g. DVB-S, DVB-C, radio and MPEG DASH).
Typically, synchronized play-out between different content processing devices may be achieved by an inter-destination media synchronization (IDMS) technique. IDMS is based on delaying play-out of all receivers to the most-delayed receiver such that synchronized play-out is achieved.
The problem with delaying all other receivers to be in line with a HAS streaming device is that in current HAS implementations play-out delays may be in the order of tens of seconds. Hence, achieving synchronized play-out means that all other devices need to be delayed by the same amount. Delaying a media signal for tens of seconds in a wide variety of devices may however create unforeseen problems. For example, a regular set-top box (STB) configured for receiving and decoding a DVB signal may have insufficient memory to store the DVB stream for half a minute. Hence, an IDMS-synchronized social TV service (e.g. “watching apart together”) may not be feasible between a regular STB and a HAS client.
Further, in live streaming applications and streaming applications that allow user interaction, it is desired and—in some cases—even stipulated by law, to have a maximum allowed end-to-end delay for the delivery and presentation of the media signal.
From the above it follows that the play-out delays introduced by HAS streaming seriously degrade the user experience and blocks large-scale commercial application of HAS streaming.
Hence, there is a need in the art for improved methods and systems for low-latency adaptive streaming that allows for optimal low-latency play out while providing a high user experience. In particular, there is a need in the art for methods and systems that allow for low-latency adaptive streaming of content to heterogeneous devices and delivery schemes.